Hey @map-g, thanks for opening a pull request for this, always happy about contributions 👍

It makes sense to add more control over the Errorhandler to Framework X, I'm interested in why you need this feature. Can you share a short example here to help us understand your use case for this?

Furthermore, the pull request appears to be in good shape. However, I believe we should include some additional tests to ensure that this new feature works as expected.

I also talked with @clue as we have plans to change a few things about the Errorhandler in the future. For instance, we intend to remove the Errorhandler from the RouteHandler, rename it to ExceptionHandler, and give more control over this in total. At the moment, we do not have a precise timeline for when this will be added to the project. However, it is inevitable that there will be some BC-breaks involved in the process. The whole BC-break topic also depends on giving Framework X a first version on GitHub, which is our next priority.

Still trying to figure out if we should use your suggestion as a transitional solution until we tagged the first version and apply our planned changes to the Errorhandler. Interested in your thoughts on this.

Hi Simon,
Thanks for your reply! We need this feature because we are building a JSON API and we do not want to respond in HTML format in case of "404/Not Found". Generally it feels counterintuitive if you supply an ErrorHandler via a container that is used sometimes and sometimes not (BTW: shouldn't the @Final annotation be removed from the ErrorHandler class, because you have to inherit from it to create a custom ErrorHandler?).
Would have preferred to get the ErrorHandler from the container (already passed to the RouteHandler), but that will lead to problems if multiple containers are added as handlers (and causes errors in related tests).
I have added a test, but that fails during CI for older environments (likely due to the - now fixed - phpstan/phpstan#152 ?). Would need some help/advice how to deal with this.
I agree that this PR should only supply a transitional solution and that error handling should be more controllable in general.

@map-g As you may already know, we're currently working on a first version for Framework X which should go live tomorrow, see https://twitter.com/x_framework/status/1762499173830778907.

In preparation for this release, we've been brainstorming a ton of new features, including the possibility of supporting JSON responses. This is definitely on our roadmap and will probably be a feature addition in the near future! While it might not make it into tomorrow's version, we're confident it will be included in an upcoming release.

As there will be some refactorings and additions to the whole handler structure anyway, I think it's best we close this for now as we also expect to pick this up in the near future. We can't say for sure what the new handlers will look like as of today, so in my opinion it's best to focus on that first and then revisit this topic afterwards 👍